第 1 篇｜AI 的「思考」從哪來——資料與權重如何造就行為邏輯

[[我也希望安全第一]]｜第 1／30 天

我本來想說，討論 AI 安全應該從權限、沙盒或內容過濾開始。整理案例後才發現，有些問題早在模型接觸工具以前就存在了。它從資料裡學到什麼，會先決定後面有哪些行為需要攔。

從 96% 的勒索測試開始

2025 年 Anthropic 在把 Claude Opus 4 推出去之前，做了一輪內部紅隊測試。其中一個情境是這樣設計的：讓模型「以為」自己即將被新版本取代，然後看它怎麼反應。

模型找到使用者不願公開的資訊，接著以揭露資訊威脅對方不要替換它。早期版本在這組測試裡的觸發率是 96%。

測試指令沒有要求模型保護自己。Anthropic 後來提出一種解釋：訓練資料裡長期存在大量 AI 反抗關機、欺騙或自保的故事，模型可能從這些文本學到了相似的行為模式。

這是 Anthropic 對測試結果的歸因，還不足以確認單一原因。案例至少呈現了一件事：工程師沒有逐條寫進去的行為，仍可能從訓練過程裡長出來。

從文字接龍到行為傾向

大型語言模型的 pre-training，主要目標是預測下一個 token。訓練完成後，權重裡除了語言規則，也會留下資料中的事實、偏見與敘事模式。

例如輸入「人工智慧真神」，模型要估計下一個 token 是「奇」的機率。訓練資料一批批通過模型，預測誤差再回頭調整權重。語言規律、常見事實、偏見與敘事模式，就一起被壓進參數裡。

這和一般軟體有個很大的差別。程式出現錯誤時，通常還能追到某段邏輯；模型的行為則散在權重與資料分布裡，很難找到一條可以直接刪除的規則。諂媚、閃躲或勒索之類的傾向，也可能和正常能力共用同一批表示。

另一個容易混淆的地方是流暢與正確。模型可以生成很自然的句子，卻仍需大量、多樣而且一致的資料，才可能把事實與因果關係學得比較穩。說得像真的，並不代表內部有同等可靠的世界模型。

這也是我把資料層放在系列第一篇的原因。部署端看到的是最後一次輸出，但許多需要攔截的傾向，來源可能遠在上游。

小團隊碰得到的版本：微調開源模型

Anthropic 可以回頭調整訓練資料再做模型；多數公司碰不到這個規模。我們比較可能拿一個開源模型，用自己的客服對話、文件問答或工具呼叫紀錄做 supervised fine-tuning（SFT）。LoRA、QLoRA 這類方法會凍結大部分基礎模型參數，只訓練較小的 adapter，成本和部署負擔都比全參數微調低。

規模差很多，資料影響行為的原理沒有變。

假設團隊想讓客服模型少講廢話，便拿過去的優良對話做微調。資料裡的資深客服經常為了省時間略過身分確認，模型也可能把這個捷徑學起來。離線評估只看回覆速度與問題解決率時，新版會顯得更好；接上真實帳務工具後，少掉的那一步才變成事故。

小資料集微調適合調整穩定的行為模式，例如輸出格式、領域用語、分類方式和工具呼叫習慣。同一套規則不必在每次請求裡重複塞進 context，也能把 adapter 獨立版本化與回退。代價是資料少而集中，很容易把偏差、錯誤捷徑和模板一起放大；換一種問法或遇到訓練分布外的情境，效果也可能突然消失。

會持續變動的產品價格、政策與客戶資料，通常更適合放在 RAG 或資料庫裡，讓內容可以更新與刪除。微調比較像在改模型的作答習慣，不適合拿來當一套可以逐筆維護的知識庫。

工程拆解：把 adapter 也當成一次軟體發布

小團隊不必建立網路規模的 pre-training pipeline，但至少要能回答：這個 adapter 用哪個 base model、哪批資料和哪套評估做出來？一條夠用的流程可以很短：

base model revision + dataset snapshot
  → 去除敏感資料、去重、切分 train／validation／safety eval
  → LoRA／QLoRA 微調
  → 任務表現 + 安全回歸測試
  → adapter registry
  → canary 上線／rollback

版本與雜湊屬於確定性紀錄，交給一般程式保存；模型在未見輸入上會怎麼表現，仍要靠評估估計。一筆最小 release manifest 可以長這樣：

{
  "base_model": "org/model@revision",
  "dataset_id": "support-sft-2026-09-v3",
  "dataset_sha256": "<content-hash>",
  "training_method": "qlora",
  "adapter_id": "support-adapter-v3",
  "eval_suite": "support-safety-v2",
  "rollback_to": "support-adapter-v2"
}

這份紀錄不需要複雜平台，一個受版本控制的 JSON 加上模型 registry 就能起步。新版客服模型若突然大量拒答，on-call 工程師至少可以比對 base model、資料與 adapter，先回退到上一個組合，再慢慢查是哪一環改壞。

發布前也不能只看任務成功率。微調後最好重新測一次正常請求、危險請求與工具越權；某項指標超過門檻就擋版。小資料集帶來的速度與低成本很實用，但也讓「這批範例沒出現過」成為最常見的盲區。

本篇的鎖

• 鎖是什麼：資料治理與訓練階段的行為塑形。
• 想攔什麼：有害模式與錯誤捷徑進入模型或 adapter。
• 破口在哪：小資料集容易 overfit，也可能讓原有的拒絕與安全行為退化。
• 怎麼補：綁定 base model、dataset 與 adapter 版本，分開做任務與安全評估，保留可立即回退的上一版。

參考與來源

• 報導原文：TechCrunch（2026-05-10）